(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 
International Bureau 

(43) International Publication Date 
7 February 2002 (07.02.2002) 




PCT 



iiiniiiiiBBiiiiiBiiiiiiiiiiiiiiiii^ 

(10) International Publication Numtier 

wo 02/11459 Al 



(51) Internatioual Patent Classificatiou^: H04Q 3/00 

(21) InteruatioaalApplicalioD Number: PCT/EPO 1/08854 
<22) liUeraational Filing Date: 31 July 2001 (31.07.2001) 



(25) Filing Language: 

(26) Publication Language: 

(30) Priority Data: 

0065009X0 



English 



2 August 2000 (02.08.2000) EP 



(71) Applicant (for all designated States except US)i A£- 
PONA LIMITED [GB/GB]; Inieirpoint Building, 20-24 
Yoric Street. Belfast BT15 1 AQ (GB). 



Liam (GB/C}B|; Hour Winds, Belfast BT8 6JX (GB). 
DALTON, Kieran [GB/GBl; 11 Glenmore Manor, Lis- 
bum BT27 4B7 (GB). 

(74) Agents: WELDON, Michael, J. et al.; c/o John A. 
O'Brien & Associates, Third floor, l>uncairn House, 14 
(Ilaiysfort Avenue, Biackrock, County Dublin (Ili). 



English (81) Designated States (nationaiji AE, AG, AL, AM, AT, AU, 
AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CO, CR, CU, 
CZ, DE, DE (uiility model), DK, DK (utility model), DM, 
DZ, EC, EE, ES, FI. GB, GD, GE, GH. GM, HR, HU, ID, 
IL, IN, IS. JP, KE, KG, KP, KR, KZ, LC, LK, LR. LS, LT. 
LU, LV, MA, MD, MG, MK. MN, MW, MX, MZ, NO. NZ. 
PL, PI, RO, RU, SD. SE, SO, SI. SK, SL, TJ, TM, TR, TT, 
TZ, UA, UG, US, UZ, VN, VU, ZA. ZW. 



(72) Inventors; and 

(75) Inventors/Applicants (for US onfy)\ 



(84) Designated States (regional)', AR1PO patent (GH, GM, 
MCQUILLAN, KB, LS. MW, MZ. SD, SL, SZ, TZ, UG, ZW), Eurasian 

{Continued on next page] 



(54) Title: GATEWAY TO ACCESS NETWORK RESOURCES 



10, 13, 14 



SetviceAp. 




FEght Portal 




Shopping 
Portal 




PartayAPI 









Appications 
IntErfdoes 



Open (Parlay) APIs 



22 



? 



23 



COR8ABU5 



Open (Partey) APIs 



(57) Abstract: A gateway (1) has a platfonn on which re- 
sides a CORBA bus (22) an inner layer (23) of Parlay APIs, 
and an outer layer (24) of network service interfaces for 
controlling network resources (2). The gateway (1) also 
comprises application interfaces (20) and Parlay APIs (21) 
residing on remote platforms which also host applications 
(to, 13, 14) wishing to access the network resources (2). 
The network resources (2) interfece directly with the Par- 
lay APIs<23) if they have Parlay APIs themselves, or oth- 
erwise with the interfaces (24). On the application side, 
the application interfaces (20) are provided as Java Beans 
which may be instantiated by an XML intexpreter in re- 
sponse to high level XML commands defining application- 
side interiacing requirements. 



Network Service 
Interfaces 



I HUi 



o 



MSC 



PartayAPI 
SMSC 



MSC 



BNSDOCID: <WO ^021145BA1.L> 



wo 02/11459 Ai iniuiiBffiniiinniininigiiuiii - 



patent (AM, AZ^ BY. KG, KZ, MD, Rl J, TJ. TM), European 
paleni (AT, BE. CH, CY, DE, DK, RS, H, FR, GB, GR, IE, 
rr. LU, MC, NL. PT. 55E, TR). OAPI patent (BF, BJ, CF. 
GG. CI. CM, GA, GN. GQ, GW, ML, MR, NE, SN, TD, 
TG>. 

Published: 

— with international search report 



before the expiration of the time limit for amendi^ the 
claims and to be republished in the event of receipt <^ 
amendments 



For two'letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations" appearing at the begin- 
ning of each regular issue of the FCT Gazette, 



BNS0OCI0:<«WQ. 



.021146aAlJ_> 



wo 02/11459 



PCT/EP01/IM1854 



-1- 

GATEWAY TO ACCESS * NETWORK RESOURCES 

INTRODUCTION 

5 

Field of the Invention 

The inveaition relates to a gatewa.y for allowing interaction of an operator's network 
resources (for example HLR, SMSC, or an IVR platform) with applications for 
1 0 provision of user services. 

Prior Art Discussion 

It is known for network subscriber services to be provided by applications. However, 
1 5 heretofore such applications have typically been hosted in the operator's network, for 
example, pre-paid, call forwarding, or voice mail services. A problem with this 
approach is that detailed knowledge of the particular systems is requii^ to program 
them for the interaction required. This is time-consuming and expensive, and allows 
limited flexibility . 

20 

This is one of die reasons \rtiy the "Parlay'* standard was developed to provide a 
mechanism for open APIs allowing applications located either within or without the 
network to access network nodes. While this is an important development, theie is a 
need for a gateway to make use of the Parlay standard to allow simple and flexible 
25 linking of network nodes with applications with minimum lead time. Achievement 
of a short lead time is particularly important for network operators as they strive to 
provide an ever-increasing variety, of subscriber services to maintain subscriber 
numbers and increase revenues. 
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Intemational Patent Specification No. WOOO/42760 (Ericsson) describes a method 
of accessing a service node from a networic end temiinal, in which the network has a 
VoIP portion and a cellular portion. * While this appears to be effective for die 
particular requirement involving VoIP, fliere is a need for a gateway to allow 
5 versatile access by a wide range of applications to a wide range of network resources. 

TTie invention is directed towards providing such a gateway. 

SUMMARY OF THE INVENTION 

10 

According to the invention, fliere is provided a gateway for interaction of 
applications widi tdeconununication network resources, the gateway comprising 
means for interfacing with said applications and means for interfacing wifli said 
network resources, characterised in diat, 

15 

the network interfacing means comprises: 

an outer layer of network service inter&ces comprising means for 
interfacing with and controlling netwoik resources; and 

20 

an inner layer of open-standard APIs comprising means for interfkdng 
with networic resources having corresponding open-standard APIs and 
for interfacing with network service inter&ces of die outer layer. 

25 In one embodiment, the gateway further comprises a middleware bus residing 
between said application interfadng means and said network interfacmg means inner 
layer. 

In another embodiment, said middleware bus complies witii the CORBA standard. 

30 
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In a furtbex embodiment, die gateway comprises a service gateway comprising inner 
layer open-standard services, outer layer service level programs, and means for 
managing interaction between the service level programs and network traffic. 

5 In one embodiment, the service layer programs comprise means for providing call 
state machines for managing coinmunication dialogue. 

In another embodiment, the service gateway comprises a notification demultiplexer 
comprising means for dispatching network notifications to the service logic programs 
10 and to applications. 

In a further embodiment, the outer layer comprises a network gateway comprising 
signalling stacks and means for performing translation between said stacks and the 
service logic programs of the service gateway. 

In one embodiment, the inner layer comprises: 

an open-standard framework interface to the middleware bus, and 

20 an open-standard service inter&ce to the middleware bus for interaction with 

applications. 

In one embodiment, the gateway comprises a framework comprising management, 
provisioning, subscription, and security functions to the outer layer and to tiie inner 
25 layer. 

In another embodiment, the gateway conrprises platform resources for providing the 
following functions to the inner layer and to the outer layer: 

30 a persistent data store for control and configuration tables; and 
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a communications function for internal communication which does not use a 
distributed object middlewaxe communication mechanism; and 

5 an event manager providing a standard inter&ce to functions widiin the 

gateway for receiving events, for classifying received events into information, 
error, and critical categories, and for logging the events. 

In one embodiment, said platform resources further comprises a timer function 
1 0 comprising means for invoking and cancelling timers for functions of die gateway. 

In one embodiment, die gateway comprises: 

a management entity for routing gateway management signals; 

15 

a Web server linked with the management entity and comprising means for 
communication vrith management inter&ces on separate hardware platforms; 

a platform manager linked with the management entity and comprising 
20 means for controlling start-up and shut-down of a primary hardware platform 

for the inner layer and the outer layer. 

In one embodiment, the means for interfacing with die applications comprises an 
application-side layer of components having an application interface and logic and a 
25 network-side layer comprising open-standard APIs for coimnunication with the 
open-standard APIs of the inner layer. 

In another embodiment, the application-side layer and die netwoik-side layer are 
present on a platform for each application and said platforms are remote from a 
30 platform ofthe inner layer and the outer layer. 
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In another embodiment, the application-side layer comprises re-usable objects and 
means for mstantiating the objects to provide a component. 

5 In one embodiment, said -instantiation means comprises an XML intezpreter 
comprising means for interpreting user inputs of high-level interfacing commands. 

According to another aspect, there is provided an aj^plication client for interfacing 
between an application and gateway open-standard APIs providing access to 
1 0 network resources, the client comprising: 

a core of open-standard APIs, and 

re-usable objects, and means for instantiating said otrjects to provide 
1 5 components widi logic and an application interface. 

In one embodiment, the instantiating means comprises an XML interpreter, and a 
user interface for directing input of high level XML conunands defining interfacing 
requirement. 

20 

In another embodiment, the application client fordhier comprises reusable utility 
objects, and means for instantiating said objects to provide components for logging, 
tracing, database access^ and timer functions. 

25 DETAILED DESCRIPTION OF THE INVENTION 

Brief Description of the Dravyings 
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The invention will be more dearly understood from the foEowing description of 
some embodiments hereof, given by way of example only with reference to the 
accompanying drawings in whidi:- 

5 Fig. 1 is a diagram illustrating the context of a gateway of the inventipi^ 

Fig. 2 is a diagram illustrating logical structure of the gateway. 

Fig. 3 is a diagram illustrating netwoik-side structure of the gateway in detail; 
10 and 

Fig. 4 is a diagram illustrating application-side structure of the gateway in 
detail. 

15 Description of the EmbndiTn«m*« 

Referring to Fig. 1, a gateway 1 interacts on one side witii networks 2 of one or moic 
operators. The networks 2 include bodi fixed-tine and wireless networks, although 
they may be of only one such type. This side of fte gateway 1 tdtimately interfaces 
20 wifli subscriber mobile phones 2, computers 4 and other user devices. On an 
application side the gateway 1 interfaces with applications 10 hosted by the network 
operators, and (via a firewall 11 and the Intemet 12) with commercial portal 
applications 13 hosted by ASPs and with corporate applications witibdn an Intranet 
14. 

25 

hi more detail, referring to Fig. 2 the applications 10, 13, and 14 include free "0800" 
services, an airline fUght portal, and a shopping portal in an illustrathre example^ On 
flie network side 3 the network nodes indude a HLR, MSCs, and an SMSC. The 
gateway 1 has a four-layer structure of layers 20, 21, 23, and 24 and a central 
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CORBA bus 22- The purpose of the gateway 1 is to allow the applications to access 
the networic resources. 

The layer 20 comprises interface components configured to suit the applications. 
5 Each interface component includes an application interface, a Parlay interfece, and a 
logic in-between. 

The layers 21 and 23 each comprise open Parlay APIs, in die layer 21 suitable for 
interfacing widi the layer 20 component Parlay interfaces, and in the layer 23 
10 suitable for network-node interfedng. Such APIs are, at an abstracted level, 
specified in the Parlay specifications. 

The layer 24 comprises network service inter&ces for interlacing with and controlling 
network resources. Thus, at a high level there is symmetry of die gateway I around 
1 5 the^COKBA bus 22, 1^ middleware between the Parlay APIs. 

As iDustrated by the arrows some of the appUcations interface with the layer 20, 
while others have a Parlay API and so interface directly with die layer 2 1 . Likewise, 
some network nodes interface with the layer 24 and others direcdy with die Parlay 
20 APIs in the layer 23. However, direcfly or indirecdy, all interactions pass through 
the Parlay layers 21 and 23 and so these layers and die CORBA bus 22 act as a 
central middlewan core of the gateway 1. 

Referring now to Fig. 3 the gateway 1 comprises a platform providing the layers 23 
25 and 24 and die CORBA bus 22, OA & M systems 28 are linked to the platform. The 
top layers 20 and 21 reside in separate computers linked to the CORBA bus 22. 

These OA & M systems 28 comprise an enterprise operator 28A, a service supplier 
28B, a framework operator 28C, a management user interface 28D, and an external 
30 operator systems 28E. 
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The layer 24 is implemented primarily by a network gateway 31 and by service logic 
programs in a service gateway 32. The layer 23 is implemented primarfly by services 
and a Parlay interlace 41 in the service gateway 32 and by a framework iParlay 
5 interface 40 in a framework 36. 

Also, both layers 23 and 24 are indirectly accessed by the various OA & M systems 
28. Also, the platform comprises a Web server 30, a platform resources bus 35, 
platform resources 37, platform managers 38, and a management enti^ 39. 

10 

The platform resources 37 include a CORBA event manager 37A and a CORBA 
alarm manager 37B. 

The resources 37 also comprise non-CORBA APIs as foUows:- 
15 database API 37C, 

communications API 37D, 

timer API 37E, 

memory manager API 37F, 

configuration parameter API 37G, and 
20 trace/log API 37H. 

The manager 38 comprises a platform manager 38A, an account manager 38B, a 
network management MIB 38C, and a network resource manager 38D. 

25 The following describes the layers 23 and 24 in more detail. The framework 36 and 
the service gateway 32 are each linked with the CORBA bus 22 by Parlay mterfaces 
40 and 41 respectively. Eadh Parlay interface provides an API and interfece 
instantiation for external access. Two interface categories are provided. The Parlay 
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fi'amework interface 40 provides surround capabilities supporting management of ifae 
service internees 41 and providing applications with secure and trusted access and 
discovery of the services provided. The Parlay service interface 41 provides 
applications with an abstracted programming API to a range of network services and 
5 information. 

Framework 36: 

The framework 36 provides common service functionality as reusable service 
elements. The framework 36 provi4es the following: 

10 

• Management: Simple framework management and service management tasks 
such as interfadng between services and Parlay management and external 
management systems 28, providing service deployment and configuration, service 
start, and service stop. When deploying the service, managemoit database tables 

15 and communication diaimels wifli platform resources 37, service gateway 32, 
and the network gateway 31 are created. 

• Provisioning: Definition of service configuration parameters for the Parlay APIs 
of the layer 23 on either a global basis or on a limited addressing or user group 
range such as setting levels for event and alarm management. In addition, 

20 common provisioning allows related services to share a common provisioning 
strategy, 

• Subscription: Registration of users for service use induding setting trigger events 
of interest to the application operation. Because this is a common subscription 
interface it provides a uniform approach for users to be associated with different 

25 services. 

• Security: The framework 36 includes a security interface with industry standard 
security algorithms. 
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The framework 36 is persistent. That is, if for any reason the gateway 1 is shut down, 
then when the framework is returned to an active state, all triggers, subscriptions and 
other settings are restored. 

5 Service Gateway 32: 

Tbie service gateway 32 manages interaction between the Qeiyet 24) service logic 
programs and network traffic delivered via the network gateway 31. In order to 
achieve this, the service gateway 32 supports the state model required by a particular 
Parlay service (of the layer 23) for a ghren network resource protocol. For example, a 

10 call control services executing in die service gateway 32 can send and receive 
messages to and from the network gateway 31 via an appropriate service logic 
program. This abstract call control service may be provisioned and configured for 
use with INAP, SIP etc. The service logic programs in the service gateway 32 
provide INAP and SIP basic call state machines in order to manage die 

IS coxnmunication dialogue. 

The service gateway 32 uses the functionalior provided in the framework 36 
(subscription, provisioning etc.), to manage die association between die subscribed 
trigger events of the applications and the (layer 23) Parlay service instances, vidth the 
20 (layer 24) service logic programs, effectively multiplexing service subscriptions. 

The service gateway 32 thus provides a notification demultiplexer, which dispatdies 
network notificadons, firstty to the appropriate service logic program and if required, 
to the application. 

25 

Network Gateway 31; 

The network gateway 31 .implements translation between vendor-supplied stack 
primitives and the service logic programs of the service gateway 32. It also manages 
die transaction or dialogue associations for new or ongoing communications 
30 between the networks and die services. 
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The configuration of the network gateway 31 provides consisteiit mappings between 
the service logic programs executing within the service gateway 32 and the network 
resources interfacing with the gateway 1. 

5 

A combination of the service gateway 32 service logic programs and functionality of 
the network gateway 31 provides the layer 24 network service interfaces for 
interfacing with and controlling the network resoiurces. 

10 Platform Resources 37: 

These are generic support resources for access and use by the other functional 
components of the gateway. These are considered separately from the generic 
framework resources, as fliey are not limited to the execution of fiie services alone. 
The following are the platform resources: 

15 

• Database 37C: A persistent data store for all control and configuration tables, 
provisioning data and subscription data. In addition, if execution of die service 
also requires persistent data storage, the service can make use of the database 37C 
via a published API. 

20 

• Commimications 37D: The gateway 1 uses CORBA communicaticms in the 
architecture in order to realise a distributed solution. However, not aO inter- 
process coxYununications requires the use of CORBA, and a communications 
library and programming interface is used to ensure consistent and portable 

25 implementation of all conunimications on the gateway 1. This resource is 
responsible for managing and controlliag the communications queues and 
sockets in a platform-independent maimer. 

• Event Manager 37A: The components of die gateway 1 generate events in order 
.30 to provide an indication of their operation. The event manager 37A provides a 
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Standard interfoce for all components to log events in a consistent manner. It 
collects the events, and manages the logging of the event to logs. The event 
manager 37A supports Ae following classifications of event: 
1. Information 
5 2. Error 
3. Critical 

The classification of the event is not known by the component generating die 
event, rather the eveiit manager uses a configurable event management table to 
define the event details. In this way, events can be reclassified via the event 
10 management table. The table can also be used to control the destination log for 
the event and define additional event infomiation text to be included in the event 
log. 

Through the event management table, events can be defined as 'billable*, in 
IS which case the event shall be considered appropriate for billing and shall be 
written to a billing log for later billing processing. The billing strategy is to 
generate billing logs and raw data for billing processing. The content of these 
billing logs is configurable by the gateway operator via the management entity 39. 
The billing logs can then be supplied to a mediation system to generate tbe 
20 charging records for input into a customer billing system. Complete billing 
flexibility is therefore available to the operator of the gateway. 

All events have a configurable event level defined in the event management table. 
The gateway 1 can be configured by the operator to support an event threshold 
25 level. By only supporting the logging of events by fiie event manager to those 
below the event level threshold, all event log^g can be controlled dynamically. 

• Alarm Manager 37B: The alarm manager 37B is a special case of the event 
manager. It provides a standard alarm API and many of the same configurable 
30 properties as the event manager as described above. However it is considered to 
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be a separate function from the event manager, as the alarm manager 37B also 
accommodates alarms generated by the imdeilying network resources and filtered 
through the network gateway 31. In addition, when the networks, services, or 
other components raise an alarm, the alarm manager 37B, in addition to logging 
5 the alarm, shall, if required, also report the alarm to the external management 
user interface 28D and to the network management MDB 38C via the 
management entity 29. A configurable alarm management table is used to define 
alarm dassificaticms and reporting. 

10 • Timers 37E: Many of the communications dialogues in operation wiOiin the 
gateway require the use of timers to ensure that system resources are not locked 
as a result of failure to complete or continue the expected dialogue. The gateway 
platform indudes a generic, platform-independent timer management function 
and programiming API. This is used to invoke, and cancel timers, and indicate 

15 when timers have elapsed. The exact timer values are configurable via a timer 
management table. 

• Memoiy Managa 37F: This standardises and simplifies all dynamic memory 
operations carried out on die platform. This resource is primarily to simplify 

10 portability across multiple hardware platforms. 

• Cparains 37G: The gateway 1 indudes a common configurable parameters 
(Cparams) library. AD processes that require configuration use this common 
resource, and the settings of the parameter values themsdves and the ability to 

i5 refi-esh die current configuration of the individual processes are controlled via the 
management entity 39. 

• Trace / Loggung 37B: Informational messages regarding the operation of the 
gateway components can be provided by this fimction for inspection by the 

10 gateway operator. In addition the level and amount of information recorded can 
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by configured on an individual process basis through flie use of Cparams, 
allowing the degree of tracing and logguag to be dynamically controlled. 

Management Entity 39: 
5 The management entity 39 is respons9>le for managing and configuring all key 
processes and components within the platform. The management entity is itself a 
process and provides an HTTP interface to the management user interface via ibe 
gateway WEB server 30. The main fimctionality provided by the management entity 
39 is: 

10 

• Platfbrm Resources: The management entity 29 interfaces to the Platform 
Resources in order to manage all database and configuration data, and interact 
wiA the Event and Alarm Managers to ensure delivery of relevant information to 
the required destination (e,g. GUI, external systems eto.)- 

15 

The gateway 1 is highly configurable via the Management Entity. This provides 
the gateway operator with maximum control over the platform operation. Each 
configurable pararheter has a default value (set during installation and used 
during process start-up), and a range of permissible values. 

20 

• Platfcmn Manager 3&A: The platform manager 38A is responsible for the start- 
up/shutdown of the gateway itself and management of platform resources such 
as the database. In addition the platform manager provides process management 
control indttding the following. 

25 Pprocess start-up/shutdown. 

Process status monitoring. The platform manager 38A shall attempt auto restart 
of process if configured to do so. 

Process trace control. Providing a mechanism for support staff to configure the 
level of trace provided for troubleshooting. 
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Process statistics control. A mechanism for obtaining counters for process 
operation and traffic upon command or at regular configurable intervals. 

• Account Manager 38B: Providing basic account management support for the 
5 external users that require access to the gateway. Each external user can be 

classified to provide different categories of access to the gateway. The accoimt 
manager 38B is responsible for providing the appropriate Parlay Interface access 
to those accounts that have been validated for gateway use. 

10 . • Network Management MBB 38C: A MIB defined for interoperability wiA 
external OA&M systems and SNMP is provided. 

• Network Resource Manager 38D: Each supported network resource shall 
provide a proprietary mechanism for configuration of the resource and 

15 interrogation of the current resource status. The network resource manager 
provides a common and consistent view of all underlying network resources. 

WEB Server: In addition to the platform and process management provided by the 
management entity 39, flie gateway 1 includes a Web server 30 to support the 

20 management interfaces. The management systems communicate wifli the Web 
server interfaces via HTTP. The Web management interfaces use a combination of 
JSP's, Java Beans and servlets. This approach allows the management interfaces to 
be distributed from the Causeway platform if required. Communication between the 
inter&ce management logic, represented by the servlets and the Parlay interfaces 

25 supported by the fiamework and service gateway are conducted over CORBA, ffar 
Hxe Framework Operator, Enterprise Operator and Service Supplier interfaces 
defined in the Parlay specifications. In addition the management logic required to 
interface to die management user interface 28D communicates with the management 
entity 39 via a proprietary internal messaging protocol. 

30 
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The foUowing describes the external management system 28. 

Management User Inteiface 28D: Provides a basic user interface to control the 
management and configuration of flie gateway 1 . Jn addition to a GUI to cany out 
5 standard commands and display results, a script-based component is also included to 
allow rapid installation and configuration of the gateway* The management user 
interface 28D is primarily concerned with platform operation, and is strongly linked 
to the functions provided via flie management entity 39 and the platform resources 
37. 

Framework Operator 28C: Supports basic configuration of the Parlay interface 40, 
and is responsible for managing and specifying the types of service that are supported 
wifliin the service gateway 32, and fliat aure accessible via tfie Parlay interface 40. 

15 Service Supplier 2fflB: Enables implementations of services to be registered with the 
Parlay firamewoik intofface 40. 

Enteiprise Operator 28A: Represents the service provider as a logically separate 
entity from the underlying network operator. Although the enterprise operator 28A 

20 can also be the gateway and network operator, this logical separation introduces the 
potential to open up new business relationships. This optional separation between 
network operator and service supplier, provides support for service wholesaling 
(ASPs) and virtual network operator relationships, and allows large coiporate or key 
accounts the capability to become more in control of the services and tailor their use 

25 to specific needs. 

The enterprise operator 28A role in the gatevtray 1 is required iirespective of whetihier • 
there is a logical business distinction. The enterprise operator 28A is responsible for 
creating and managing the service contracts and subscriiytion accounts and 
30 relationships between applications and the services they wish to use, A hierarchical 
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subscription topology is supported through the use of service profiles and 
subscription assignment ^oups, such that groups of similar application users can 
have access to the same grouping of services. 

5 The enterprise operator 28A creates valid subscription accounts befpie an application 
can make use of fhc network services accessible through the Parlay interface 40. 

Turning again to the application side, flie applications 10, 13, and 14 execute the 
logic to provide the application experience required by the end user or dient The 
10 applications may execute locally in the gateway 1 if the operator wishes to provide 
fidl application solutions on a single platform, or (as illustrated) remotely from die 
gateway 1 and using CORBA for commimication. 

The applications 10, 13, and 14 manage the Parlay communication between the 
15 application and the parlay interface 40 in order to obtain Parlay j&amework 36 access 
and service discovery. Also, once an appropriate service has been selected for use, 
the application interacts widi the service via the Parliay interface 41 in order to use 
the required network resource functionality requested by the application. 

20 The development of applications by service providers (induding* enteiprise, virtual 
and "real* network operators), independent software vendors, and potentially end 
lisers themselves is simplified by using a Parlay client proxy (PCP) implementing the 
layers 20 and 21. This is provided to simplify the Parlay communication to the 
layers 23 and 24 and encourage application component re-use based on simple use of 

25 the services, thereby simplifying the application devdopment activity. The gateway 
operator, and parties other than the gateway operator, may use a PCP. 

In order to integrate the gateway 1 completdy within a network operators domain, 
interfaces to existing operator management systems, sudi as network management, 
30 customer care, billing etc.^, are provided. The gateway 1 support this integiation by 
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providing external access to the management entity 39 via a number of access 
protocols, e.g. SNMP, CORBA, HTTP. The gateway operator configures the 
external access provided via the management entity to support appropriate 
interoperability between gateway management functions and external systems. 

5 

Referring to Fig. 4 the PCP 50 is illustrated. The layer 20 comprises an XML 
interpreter, Parlay Beans, Utility Beans, and component applications. There is also a 
common proxy manager. The PCP 50 is hosted by the ASP together with the 
application and allows easy interfadng vrilh short lead times to tfie layers 23 and 24 
10 as illustrated in Fig. 2. The layer 21 comprises Parlay APIs. 

The Parlay Beans are re-usable objects whidi may be easily instantiated to provide 
an appUcation interfece, a Parlay interface, and logic in-between. An XML script 
function provides a user interface to allow an interfhdng component to be easily 
15 instantiated. The XML interpreter automaticaDy perfonns the low-levd mstantiation 
of the Parlay Beans to complete the interfadr^ component 

Thus, the PCP 50 comprises "raw" components for tihe layer 20, Paxlay APIs for the 
layer 21, and tools to allow simple instantiation of the layer 20 components (Ae 
20 Parlay Beans) to suit the application. 

The PCP 50 shields die application developer from the complexity of the Pailay API 
21 and from the intricacies of CORBA. It provides a number of programming 
interfaces, providing the application developer with a choice ran^ng between 

25 complete responsibility for developing applications direcfly based on fliie Parlay 
interface definition, (to layer 21), or alternatively developing a Java based application 
using a component based Java Beans. IDE or a simple XML based scripting inter&ce 
(to layer 20). The choice of interface will depend on the skill of the application 
developer and the complexity of the application to be developed. Simple applicaticms 

30 can be constructed from beans or using scripts, whereas more complex applications 
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shall require a fuller appreciation of how the Java programming interface supports 
Parlay service using flic PCP core. 

In order to simplify the development of Parlay client applications, the PCP 50 
5 exposes Parlay like Java Beans to application developers. These Beans run on tfie 
PCP Core, which consists of Java Parlay object implementations and other related 
objects. The PCP core contents are not directly accessible to the Parlay applications, 
instead they are controlled by the Parlay Beans. The core is designed to provide the 
application with full Parlay functionality but in a controlled and optimised manner. 

10 

The primary function of the PCP Core is to convert between the Parlay API which 
uses CORBA and Java implementations of the Parlay objects. The key advantage is 
that it enables the development of Parlay applications without requiring knowledge 
ofCORBA. 
15 • 

PCP Beans 

These components provide robust, efficient, reusable functionality that can be 
quickly integrated to produce PCP applications. Applications developed using these 
PCP Beans can then run against the PCP Core in an identical manner to any other 
20 PCP application. 

Although the majority of the PCP Beans may have no GUI appearance of theii own, 
their properties can be configured and they can still be assembled visually inside a 
JavaBeans IDE. 

25 

The PCP Beans enable the development of Parlay applications without requiring a 
detailed knowledge of the Parlay API. An application developer merely requires a 
conceptual understanding of Parlay and of the services operating within the gateway 
1, and can assemble applications firom several of the PCP Beans. The PCP Beans 
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provide a simpk, easy to use service creation environment for application 
development. 

There are two categories of PCP Beans provided wittt the PCP 50. The first category, 
5 known as the Parlay Beans, provides reusable functionality. The Parlay Beans 
respond to events from other PCP Beans and invoke operations on the PCP Core. 
Exainples include JavaBeans to perform authentication with the Causeway Parlay 
Gateway, JavaBeans to discover services running in the gateway and JavaBeans that 
encapsulate reusable functionality for various services running in the gateway. 

10 

The second category of PCP Beans, known as the Utility Beans, provides reusable 
functionahty that is not specific to the PCP Core. Utility Beans do not invoke any 
operations on the PCP Core. They include JavaBeans for logging and tracing, ffar 
ds^tabase access, and for timed invocations. 

15 

The XML Interpreter includes a Document Type Definition (DTD) that defines the 
interactions between the various JavaBeans provided by the PCP 50. The XML 
Interpreter enables applications to be described using XML, where each XML node 
represents one of the PCP Core or Utility Beans, and the Bean properties are 
20 represented by node parameters. 

The proxy manager is a management entity responsible for managrog the PCP 50 
and the applications that execute wiAin it. It performs application lifecycle and 
profile management functions. Application lifecyde management comprises the 
25 functionality to install, activate, deactivate and uninstall applications on the PCP 50. 
Application profile management comprises of the configuration of PCP setting fbr 
each application deployed on the platfbrm. 

It will be appreciated tiiat tiie invention provides a simple migration path fix>m 
30 current network signalling and communication protocols (2G) to new and emerging 
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technologies (3G) by acting as an adapter between the applications and network 
resources. Also, the gateway 1 can interrogate and utilise the capabilities of the 
network as a singile logical entity, rather than direcdy communicating with many 
individual network resources. The gateway 1 supports network independence and 
5 portability across vendor-supplied hardware products. In addition, the gateway 1 
provides a suite of services for administration very eflFectively. In the layers 20 and 
21 the gateway 1 allows wide application developer choice of interfaces, including 
Parlay APIs in the Java or C++ languages, . simple Java application development 
where distributed middleware is hidden from the application developer, a 
10 component-based development environment using Java Beans, and script-based 
application developments. 

In addition, the FCP includes a software development kit (SDK) emulation mode, in 
which application development using all die power and functionality of the APIs 
15 available m the PCP are combined with an integrated emulation and test fadliQr. 
This is accomplished on a single platform with no requirement for gateway layers 23 
and 24 or network coimection, so allowing application developer communities to 
develop and test application ideas in isolation from network operators and» yet in 
confidence that the application meets the demands of the standardised APIs. 

20 

The invention is not linuted to the embodiments described but may be varied in 
construction and detail. 
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Claims 

1. A gateway for interaction of applications widi telecommimication network 
resources, the gateway comprising means for interfacing with said 
applications and means for interfacing with said network resources, 
characterised in that, 

tfie network inter&cing tneans comprises: 

an outer layer (24) of network service interfaces comprising means for 
interfacing with and controlling network resources (2); and 



an inner layer (23) of open-standard APIs coinprisiog means 'for 
interfacing with network resources having corresponding open- 
15 standard APIs and for interfacing with netwoik service interfaces of 

the outer layer (24). 

2. A gateway as claimed in daim 1, wherein the gateway (1) further comprises a 
middleware bus (22) residing between said application interfacing means (20, 
20 21) and said network interfacing means inner layer (23). 

3- A gateway as claimed in daim 2, wherein said middleware bus complies with 
the CORBA standard. 

25 4. A gateway as claimed in any preceding daim, wherein the gateway (1) 
comprises a service gateway (32) comprising inner layer (23) open-standard 
services, outer layer (24) service level pingrams, and means for managing 
interaction between the service levd programs and network traffic. 



eNSOOCID: <WO ^02114SaA1J^ 



wo 02/11459 



PCT/£PDl/08854 



-23- 

5. A gateway as claimed in claim 4, wherein the service layer programs 
comprise means for providing call state machines for managing 
communication dialogue. 

5 6. A gateway as claimed in claims 4 or 5, wherein the service gateway (32) 
comprises a notification demultiplexer comprising means for dispatching 
network notifications to the service logic programs and to applications. 

1. A gateway as claimed in any of claims 4 to 6, wherein the outer layer (24) 
1 0 comprises a network gateway (31) comprising signalling stacks and means for 

performing translation between said stacks and (he service logic programs of 
the service gateway (32). 

8. A gateway as claimed in any of claims 2 to 7, wherein the inner layer (23) 
IS conq)rises: 

an open-standard framework interface (40) to the middlevsrare bus (22), 
and 

20 an open-standard service interface (41) to the middleware bus (22) for 

interaction with applications (10, 13, 14). 

9. A gateway as claimed in any preceding daim, wherein the gateway (1) 
comprises a framework (36) comprising management, provisioning, 

25 subscription, and security functions to the outer layer (24) and to ihe inner 

layer (23). 

10. A gateway as claimed in any preceding daim, wherein the gateway (1) 
comprises platform resources (37) for providing the following functions to the 

30 inner layer (23) and to the outer layer (24): 
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a persistent data store (37C) for control and configuration tables; and 

a communications function (37D) for internal communication wliidi 
does not use a distributed object middleware communication 
mechanism; and 

an event manager (37A) providing a standard interface to functions 
within the gateway (1) for receiving events, for classifying received 
events into information, error, and critical categories, and for logging 
the events* 



11. A gateway as claimed in daim 10, wherein said platform resources further 
comprises a timer function comprising means for ihvoldng and canodOing 

15 "timers fcMTftmctions of the gateway (1)7 ~ . 

12. A gateway as claimed in any preceding daim, wherein (he gateway (1) 
comprises: 

20 a management entitjr (39) for routing gateway management signals; 

a Web server (30) linked with the management entity (39) and 
comprising means for communication with management interfaces 
(28) on separate hardware platfonns; 



25 



a platform manager (38A) linked with the management entity (39) and 
comprising means for controlling start-up and shut-down of a primary 
hardware platform for flie inner layer (23) and the outer layer (24). 
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13. A gateway as claimed in any preceding daim, wherein ihc means for 
interfacing with the applications comprises an application-side layer (20) of 
component having an application interface and logic and a network-side 
layer (21) comprising ox>en-standard APIs for communication with the open- 

5 standard APIs of the inner layer (23). 

14. A gateway as claimed in daim 13, wherein the application-side layer (20) and 
the network-side layer (21) arc present on a platform for each application and 
said platforms are remote from a platform of the inner layer (23) and the outer 

10 layer (24). 

15. A gateway as daimed in daim 13 or 14, wherein the application-side layer 
(20) comprises re-usable objects and means for instantiating the objects to 
provide a component. 

15 

16. A gateway as daimed in daim 15, wherein said instantiation means 
comprises an XML interpreter comprising means for interpreting user inputs 
of high-levd interfacing commands* 

20 17. An application client for interfacing between an application and gateway 
open-standard AP^ providing access to network resources, the dient 
comprising: 



25 



a core (21) of open-standard APIs, and 

re-usable objects, and means for instantiating said objects to provide 
components with logic.and an ajipHcation interfkce. 



BNSCXXID: <WO p21146eA1J_> 



wo 02/11459 



PCT/EPOl/08854 



-26- 

18. An application client as claimed in daim 17, wherein the instantiating means 
comprises an XML interpreter, and a user interface for directing input of high 
level XML commands defining interfacing requirement. 

19. An application client as daimed in daim 17 or 18, wherein the application 
dient further comprises reusable utility objects, and means for instantiating 
said objects to provide components for loggmg, tracmg, database access, and 
timer functions. 
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